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UNICOM — The Winter Technical Meeting 


The next general meeting of the USENIX Association will be a joint meeting with /usr/group and 
the Software Tools Users Group. It will be called UNICOM and will be held in San Diego, California, 
Tuesday, January 25 through Friday, January 28, 1983, at the Town and Country Hotel. The meeting 
is being hosted by the University of California at San Diego, with Tom Uter acting as the overall local 
conference coordinator. 


The local arrangements chairperson is 


Judy DesHarnais 
UNICOM 

P.O. Box 385 

Sunset Beach, CA 90742 
(213) 592-3243 


The meeting registration packet was mailed to an extensive list November 22. If you do not 
receive the registration packet or need registration and/or accommodation information contact Ms. 
DesHarnais. 





This newsletter may contain information covered by one or more licenses, copyrights, and/or 
non-disclosure agreements. Permission to copy without fee all or part of this newsletter is granted to 
Institutional Members of the USENLX Association, provided that copies are made for internal use at the 
member campus or plant site. 


The deadline for submissions for the December issue of ;/ogin: is December 17 
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The Toronto Meeting 


The Summer, 1983, technical meeting of the USENIX Association will be held in Toronto, 
Ontario, Canada, the week of July 11. The host of the meeting will be Human Computing Resources 
Corporation. 


Boston Meeting Proceedings 


The Boston Meeting conference proceedings will be available in January. They are over 350 pages 
long and will cost about $25. The proceedings will be available at UNICOM and by mail from 
/usr/group; specific ordering information will be printed in ;/ogin: when it is available. 


AT&T Announces System V 


AT&T has announced that it plans to license and support System V, their latest in-house version 
of UNIX , early next year. 


System V will be offered as a machine-independent ‘‘standard’’ operating system for 16 and 32 bit 
computers. It will run on PDP-11 and VAX machines; AT&T has not announced what other CPU’s it 
will run on, if any. It is reported to have improvements in the areas of performance, screen editing, 
text processing, file system maintenance, and communications. 


Several levels of support will reportedly be offered including a hot-line service, consultation, 
technical seminars, newsletters, electronic mail to report problems, and periodic releases to correct 
problems. 


Details will be announced in January, 1983, and discussed at UNICOM. 


DEC Announces Supported UNIX V7 


On December 6 at the DECUS meeting in Anaheim, California, Digital Equipment Corporation 
announced that they will be offering their modified UNIX Version 7 for PDP-11’s as a standard DEC 
product. It will be orderable just as any other DEC product, with formal field service and software ser- 
vices (i.e., support) available. The product name is ‘‘V7M-11"’. The announcement stated that it will 
be offered as a binary sub-license only. 


In the announcement DEC identified the features distinguishing their product from that offered 
by AT&T as being: 


(1) support will be available; 
(2) it runs on all memory-managed PDP-11 models and is fully customer installable, 
(3) it supports all current PDP-11 peripherals; 
(4) it includes code for bad disk block handling; 
(5) it includes a complete error logger and user-mode diagnostics, and 
(6) it includes the U.C. Berkeley vi editor. 
V7M-11 will be available about May, 1983. 





“UNIX is a trademark of Bel! Laboratories. 
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Performance Issues of VMUNIX Revisited 


Preface 


At the request of the editor, I have forwarded the following report entitled ‘Performance Issues 
of VMUNIX Revisited”. Regretably, this report is now somewhat out of date and also depends heavily 
on three other reports not included here: 


1) An unpublished report by David Kashtan (circa 1979) entitled “UNIX and VMS - 
Some Performance Comparisons’’. 


2) An unpublished report by William Joy (circa 1979) entitled ‘“Comments on the Perfor- 
mance of UNIX on the VAX’’. 


3) An unpublished internal memorandum from April 1981 criticizing both the virtual 
memory performance of VMUNIX and the performance of the VAX F77 compiler. 
Unfortunately, without these other reports, much of what is contained below cannot be put into 
proper perspective. Nevertheless, it was felt that it would be of general benefit to include the following 
in ;login:. 


Thomas Ferrin 
23 June 1982 


Performance Issues of VMUNIX Revisited 
Thomas E. Ferrin 


Computer Graphics Laboratory 
School of Pharmacy 
University of California 
San Francisco, California 94143 


7 May 1981 


The 20 April 1981 memorandum from < deleted by request> discussed several VAX performance 
issues and reached conclusions very unfavorable toward the UNZX Operating System. Unfortunately, 
many of the measurements quoted for VMUNIX were either inaccurate or out of date. Since such 
measurements must be the foundation for the recently proposed change in operating systems, it is 
important to have the most up-to-date results. The VA4UNIX measurements cited below were per- 
formed during the week of 24 April to 1 May 1981 on a VAX 11/780 computer running version 4.1 of 
VMUNIX with 2.0 Mb of memory. The VMS measurements are the same as those quoted from the 
memorandum of 20 April 1981, 


There are two separate performance issues. The first deals with the operating system ‘‘paging”’ 
algorithm, certainly a crucial area in a virtual memory environment. The second issue deals with For- 
tran performance. These are summarized as follows: 


1. ‘Paging’ performance. Recent enhancements to VMUNIX have improved its paging per- 
formance considerably. The addition of a new advisory call (vadvise(SEQL) to the operating system to 
inform it that a program will be exhibiting strongly sequential behavior and thereby increasing the 
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progtam’s ‘‘page-in cluster factor’’* under such circumstances (in addition to other changes) have 


yielded the following improvements: 


Table I 
Sequential Page Access 


VMS | VMUNIX 4.0 VMUNIX 4.1 
w/o vadvise(SEQL) whvadvise(SEQL) 
CPU Time 39.0 1:07.0 1:17.2 1:17.2 
Thus, a strongly sequential program runs faster (even out-performing V4S in real time) if the 
system is told that the program has sequential access behavior. Soon it may not even be necessary for a 
program to inform the system it is sequential, since such behavior can be detected automatically by the 
system. The significance of sequential memory behavior is referred to again below. 


Of course sequential access is not the only type of memory reference behavior. The other bench- 
marks referred to in the 20 April memo are quoted below: 










Table I 
Random Page Access 


VMS | 4.0 VMUNIX | 4.1 VMUNIX 
CPU Time 31.0 SL9 1:09.6 
Real Time | 6:00.0 12:43.0 6:51.0 


Table Mii 
Gausian Page Access 


St. Dev. VMS 4.0 VMUNIX } 4.1 VMUNIX 
CPU R CPU Real | CPU _ Real 

i : X :23 15 

10 . ! : 16 


eal 
16 
18 























Thus, for random and for gaussian paging behavior the times are nearly identical throughout the 
measured range. For small programs UNIX is faster, since programs tend to get larger memory alloca- 
tions without paging from the free list (as they are forced to in VMS when they pass their working set 
quota). 

Other comments involving paging performance are: 

a) Contrary to previous information, VMUNIX does not keep all user page tables resident 

in main memory at all times. The present system keeps only the pages of currently 
resident processes in memory. Also, the 20 April memo neglected to point out that 
VMS statically allocates space for both the kernel segment tables and the contiguous 
swap area on disk. This allocation is based on the maximum possible number of 


* Note that VMUNIX does not move pages from disk to main memory one at a time as previously reported, nor has it done 
so for over a year. UNIX “pages-out"’ up to 16 K contiguous bytes (1 complete disk track) at 2 time and ‘‘pages-in’’ 4 Kbytes (8 
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Processes. Thus, if we allow for a maximum of only 10 VMS processes (a conservative 
figure), of which, say, only 1 is of the quoted hypothetical 128 Mb in size, VMS will 
allocate a fixed 20 Kbytes (128Mb*10 procs/64 Kb) of memory for kernel segment 
tables, and a fixed 1.2 gigabytes (128Mb* 10 procs) of disk space, 90% of which will be 
unused! VMUNIX, on the other hand, dynamically allocates both main memory used 
for page tables and disk paging space. Running out of resources in VMUNIX may 
delay the completion of a process, but less total resources are required and what are 
required are used more effectively. 


b) The “severe problem” mentioned with respect to VMUNIX swapping out a process 
when it was the only program in memory was a bug in the paging algorithm that has 
now been fixed. 


c) The “lock-out”? problem mentioned with respect to VMUNIX when heavy paging 
traffic was present was due to this same bug; again this has now been fixed. 


2. Fortran Differences. There are several points of interest here. First to note is that the 
work of Rafenetti at ANL is not crucial since they have adopted UNIX there. Secondly, the cited inac- 
curacy of mathematical functions is not particularly decisive either. The inaccuracies of VMUNIX's 
DEXPO are no worse than VMSs DLOG() and DLOGIO( inaccuracies. Also note that the extreme 
inaccuracy of X**Y in the VMUNIX “‘libnm’’ power function is due to a bug in the VAX hardware! (A 
microcode error in the ‘‘polyd”’ instruction, reference DEC FCO#S for the fix to this.) VMSrun ona 
system that does not have the hardware engineering change would potentially show exactly the same 
type of error. 


We are thus left with evaluation of the ‘FFT’? benchmarks. Here it is imperative to isolate the 
fortran compiler aspect of VMUNIX from the demand paging aspects of the system. This was obviously 
not done in the earlier benchmarks, since if a compute bound process fits entirely in physical memory 
on an otherwise idle system, then the real execution time must equal the program cpu time. Notice 
that this was true under VMS but not true under VMUNIX. There can only be two reasons for this. 
Either the system was not otherwise idle or the program was larger than could fit in physical memory. 
It is hard to conceive of a way that a 128 x 128 complex array could not fit into an idle 2 Mb machine. 
The FFT benchmarks were re-run on 24 April with very different results: 


Table IV 
Unloaded System FFT 


VMS “Ola” 24 Apr 1981 “New” 
UNIX Times UNIX Times Ratio 
CPU Real| CPU Real | CPU Real 
08 :26 18 
































128x128 q 08 1:43 1:2.25 
256x256 :38 338 7:13 1:1.92 
512x512 | 3:43 3:44 | 10:32 24:59 1:1.65 








These new results appear consistent with the ratio of execution speeds quoted in the past ‘‘...a fac- 
tor of 1.5 to 2.5 difference between VMS Fortran and F77”’, 

[Editor’s Note: The UNIX times above have now been improved considerably. See ‘‘F77 Perfor- 
mance” by David Mosher and Robert Corbett, published in the June, 1982, issue of slogin: (Vol. 7, 
No. 3).] 

On a loaded system the new benchmark results can be even more impressive, although direct 
comparison with times quoted in the 20 April memo are not possible since no quantitative figures were 


given to indicate what ‘a loaded system’? was. One reason to expect increased performance on a 
loaded system, however, is the fact that the FFT program exhibits strongly sequential memory accesses 


K for sequential program behavior). 
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and thus benefits greatly from the vadvise(SEQL) system call. 
Other comments in the area of Fortran performance are: 


a) A 2.12 Mb program which exhibits sequential virtual memory accesses is far from 
“humble’’. 


b) If one asks for the lowest possible priority on a machine which is not idle or otherwise 
running only programs of the same low priority, one should not expect to get much 
cpu time. 


c) The ‘needless paging’ problem mentioned with respect to ‘forced swapping’’ in 
VMUNIX was due to a previously mentioned bug in the UNIX paging algorithm. 
Again, this has now been fixed. 


Conclusions 

The picture of VMUNIX is not nearly as dismal as was previously reported. The various paging 
benchmarks quoted now run as fast as, and in the case of sequential virtual memory access even faster 
than, VMS. A kernel bug causing extraneous swapping and general system degradation during a heavy 
paging load has been fixed. The burden of responsibility for a large inaccuracy in a Fortran intrinsic 
function has been shifted from VMUNIX to the VAX hardware where it belongs. Future improvement 
in the accuracy of ali math library functions on VMUNIX is forthcoming. The important 512 x 512 
FFT benchmark performs significantly better than previously stated and, with the help of the 
vadvise(SEQL) system call and future improvements in the F77 compiler will exhibit even better perfor- 
mance in the not too distant future. 


USENIX Association Office Report 


On October 23, 1982, the new Office opened for business in El Cerrito, California (near Berke- 
ley). Since the office has opened we have been working on the mailing list for the UNICOM registration 
packet and on new and renewed USENIX memberships. The UNICOM registration packets were mailed 
in late November. The USENIX membership data base is now up to date, with the exception of a few 
for which we have incomplete paperwork. All new and renewed members have been mailed the previ- 
ous issues of ;login: for this year. 

Currently we are going through the paperwork for the institutional members that have not yet 
been sent their software distribution tape for this year. These tapes will sent out as soon as possible. 


The USENIX Office can now be reached at: 


USENIX Association 
P.O. Box 7 
El Cerrito, CA 94530 


The new phone number of the Office is: 
(415) 528-UNIX 


The Office is staffed between 10am and 2pm, Pacific Time, weekdays. Messages may be left on a 
phone answering machine when no one is available. 


Tom Strong 
Executive Director 
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USENIX Association 


Application for Individual or Public Membership 
For Calendar Year 1983 
Please type or print very clearly 


New 


Renewal [ ] With changes to existing USENIX records 
Old address: 











{ ] Individual Membership: $30 
{ ] Non-Disclosure covered by institution with source license 


[ 1 Non-Disclosure covered by institution with binary license 


Institutional affiliation: 








Nature of affiliation: 





[ ] Public Membership (Not covered by Non-Disclosure): $30 


Mailing address: 


Your name: 

















Phone: ( 





) 


Network address: 








[ ] Overseas airmail, add $9.00 
{ ] Invoice required, add $6.00 bookkeeping charge 


Check enclosed: $ 


Return completed form to: 






USENIX Association 
P.O. Box 7 
E! Cerrito, CA 94530 


You will receive a card acknowledging your membership as soon as it is processed. 


4uO af 22yfO 
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UsENIx Association 
P.O. Box 7 : . 
El Cerrito, CA 94530 First Class Mail 


Your 1983 Individual Membership 
Renewal Form is Enclosed 


Usentx Dues Increase 


The Board of Directors, at its last meeting, voted to increase the annual dues for Individual and 
Public members to $30, This increase was adopted to bring membership dues more nearly in line with 
the cost of producing the newsletter. For members attending the USENIX conferences, the new 
membership discount for registration will partly offset this increase. 


